10/29更新事項:致謝銘

對於能夠完賽我也是非常訝異，因為光是將實際工作的工作流程釐清出一個脈絡就是一個大且細緻的工程，我不太確定會有多少人看到這個系列文章，事實上，這個文章可以說是給當初迷惘在不知道一個資深前端+後端的我該怎麼再往下一個人生里程碑 - 又或者依照我喜歡的DND遊戲說法進階職業、二轉。

從一個 數據分析工作者 到 軟體工程師 到現在的 系統分析與設計 ，在這個過程中其實有非常非常非常之多的前輩與團體社群提供優質的內容，在完賽的一個月裡也是陸陸續續地詢問是否願意公開致謝與願意接受我忝不知恥的分享

前端的部分特別感謝 老莫 Kyle Mo 與 ThisWeb｜請網這邊走，在一開始剛轉換跑道時(以及現在)，清晰且豐富的內容是我了解前端最優質的內容來源。

後端的部分特別感謝ExplainThis，全端開發雙周報非常值得訂閱，能夠快速了解現行風潮的精要，更別說原本就會定期分享前端、後端與雲端的內容。

軟體思維與系統設計上特別感謝Hogan，每年固定的舉辦的小聚讓人收穫滿滿，從不同面向(FE/BE/SD/SE/SA/QA/PM/DE)、不同需求與不同階段來理解一個產品級服務是怎麼誕生並成功上線的。

職場上面特別感謝Bryan叔 和 顧職團隊，我得以成功在2025年4月獲得台灣區副總的認可成功勝任開發Leader(破格晉升，因為年資不足)，都是從分享中學習精進的關於軟體思維、產品的商業邏輯設計的知識。

同時，在職場面上也有一個幫助我非常大的貴人(? 台灣開發者在澳洲DC群 (入群連結沒有取得公開分享的授權答覆，請先到FB社群問問看🙏)，在這裡收穫到了海外的生態以及職涯發展規畫的建議，也是當我在後端+全端迷惘時釐清出擇一領域做到擁有資深Level的技術與商業實現能力，並且強調雲端的重要性，不是每個國家都像台灣一樣某種程度上都會自行DIY電腦規格與組成，雲端架構能力對於其他國家的人而言是種建置與維護長期成本最優解。

雲端架構資源我非常推薦 AWS台灣官方 與 AWS證照陪跑計畫 ，在現行不間斷與全球性的需求下，不論是人員又或是專案經理都蠻適合了解雲端這個概念。

用個8年級、90s的說法來說，要謝的人太多了，那就謝天吧，後續應該還會陸續增加致謝名單，而目前正在準備明年去加拿大或澳洲，希望有機會跟大家分享當地的山好不好爬XD

為什麼一個架構師需要哲學思維？

ChatGPT可以幫你我寫代碼，但它無法告訴我們「這個系統存在的目的是什麼」。

這正是哲學思維對架構師而言的核心價值所在。

在我是個工程師之前，我曾經做過救生員（高中時的打工）、游泳教練（是的，短時間的救生員之後我被添加上了一個新的任務）、數據分析師、登山嚮導、私廚、數位行銷策畫，甚至是塔羅師的經歷。

在眾多不同的工作內容中，有一個脈絡被我歸納出來，並且發現其實每一個工作與想要執行的事物都可以按照這個脈絡進行， 目的取向 。後來在軟體工程的世界裡，我才知道這叫做「 領域驅動 」。

系統的有機性與目的

系統，代表的是一個功能的完整實現，具有其哲學意涵與有機性。

就像生物的生命目的是延續自己一樣，每個系統的誕生都是為了實現某個特定目的：

• 檢索系統是為了在海量數據中找到我們要的資訊。
• AWS Lambda 是為了讓我們不用管伺服器即可執行代碼。
• API Gateway 是為了統一管理所有 API 入口。
• S3 並不是單純的「雲端硬碟」，而是為了滿足「任意擴展、高持久性、低成本存儲」的商業目的。

系統設計其實是一種概念化的仿生學——我們設計它的進食（輸入）、消化（處理）、轉換（計算）與目的實現（輸出）。就像一個人體：

• 消化系統 對應輸入資料的解析與轉換。
• 神經系統 對應事件驅動架構（Event-Driven Architecture）。
• 免疫系統 對應安全防護、災難復原與監控告警。
• 循環系統 對應資料流動、消息總線與 API 呼叫。

身為軟體工程師，我們必須緊緊依照「目的」來設計系統，否則就會出現災難。
想像可能會出現(根據我的日常經驗中，絕對會出現過)的情境：

• 我們打造了一個完美的 API，但它無法與真實業務對接。
• 我們花時間優化了 UI，但背後的數據流完全不符合使用者的核心需求。

這就像一頓精緻料理卻沒有主食，或一個登山嚮導卻沒有正確地圖。錯的不是材料，而是設計者忘記了「目的」。
身為軟體工程師，我們必須緊緊依照目的來設計系統，否則就會出現災難：一個不符合出廠標準的齒輪、無法讓饕客滿足的餐點，錯的不是材料，而是設計者。

Domain-Driven vs Behavior-Driven：架構師的視角差異

很多人習慣用 BDD（Behavior-Driven Development, 行為驅動開發） 來思考系統，跟著用戶的操作軌跡設計功能。

這沒有錯，特別適合產品剛起步時的驗證與快速迭代。

但就像密林是從草原逐漸生長起來的，當系統複雜度增加時，不同的操作情境會成為覆蓋陽光的藤蔓，商業邏輯的維護成本會熵增，最終達到被捨棄或重構的臨界值。

這就是為什麼架構師要掌握 DDD 的高視角。

DDD的價值在於：它讓我們從更高的視角俯瞰整個系統架構。

DDD 的價值不僅僅在於「程式碼的分層」，更在於它讓我們回歸「目的」：
領域模型 是對現實世界規律的抽象。
界限上下文（Bounded Context） 幫助我們劃定「什麼屬於這個子系統，什麼不屬於」。
聚合（Aggregate） 是我們對「事物」的完整定義，而非僅僅一個資料表。

當我們依循每一個「領域」去思考脈絡、設計操作情境、收束狀態變化，我們就能讓第一次踏入系統的開發者快速掌握規律，不會陷入行為特例構築的泥沼。

DDD 的價值不僅僅在於「程式碼的分層」，更在於它讓我們回歸「目的」：

• 領域模型 是對現實世界規律的抽象。
• 界限上下文（Bounded Context） 幫助我們劃定「什麼屬於這個子系統，什麼不屬於」。
• 聚合（Aggregate） 是我們對「事物」的完整定義，而非僅僅一個資料表。

這對AWS架構師來說特別重要，因為雲端服務的選擇太多了，沒有領域邏輯指引，我們很容易迷失在服務清單裡。
舉個 AWS 架構的例子：

如果僅用 BDD，我們可能會因使用者需要「上傳檔案」而直接放一個 EC2 + FTP。

但若用 DDD，我們會問：「在這個領域，檔案的目的與價值是什麼？」

• 是單純存放？ → S3。

• 需要版本管理？ → S3 + DynamoDB metadata。

• 需要事件觸發？ → S3 + EventBridge + Lambda。

• 需要跨區分發？ → S3 + CloudFront。

DDD 幫助架構師避免只看到「行為」而忽略「目的」。

AI時代下的架構師價值

特別是現在，當算力大爆發讓AI生成代碼的速度遠超人工coding時，Domain知識的深度和對業務邏輯的掌握，成了真正的競爭壁壘。 能否理解業務領域與目的，並轉譯成架構與設計成為了最重要以及最需要的能力。

這就是我想在30天跟大家分享的核心：不只是分享怎麼用AWS工具，而是分享我用領域驅動的思維來設計雲端架構。

AI 可以補齊程式碼的語法細節，但它無法回答：

「這個服務應該放在單體架構還是微服務裡？」
「要不要分割資料庫？業務上為什麼需要分割？」
「跨國部署是單純的技術選項，還是業務戰略的需求？」

這些問題背後隱藏的，是 哲學思維：追問「為什麼」，而不僅是「怎麼做」。

架構師的日常困境與思維轉換

很多人以為架構師的工作就是「畫架構圖」或「挑選 AWS 服務」。事實上，這只是冰山一角。

真實世界中的架構師，面臨的是以下困境：

1. 需求永遠模糊

• 業務部門常常說：「我需要一個像 Uber 一樣的東西。」
• 這句話到底代表什麼？叫車？支付？即時定位？還是司機評分？
• 架構師要能將模糊的願景拆解為清晰的系統邊界。

2. 技術永遠變化

• 今天 AWS 出了一個新服務，明天可能 Google Cloud 或 Azure 提供了更便宜的替代方案。
• 架構師要避免「追逐潮流」的陷阱，而是回到目的：這個服務是否真的幫助我們實現業務？

3. 團隊認知差異

• 前端工程師希望快速迭代。
• 後端工程師希望數據一致性。
• 運維工程師希望高可用性。

架構師要能在這些拉扯之間找到「目的導向的平衡點」。

哲學與工程的交會：從亞里士多德到雲原生

古希臘哲學家亞里士多德提出了「目的因（Final Cause）」的概念：一個事物存在的理由，不是因為它是由什麼構成，而是它要達成什麼目的。

一把刀的目的是切割。
一艘船的目的是航行。
一個系統的目的是解決特定的業務問題。

這和我們在軟體架構中的追問高度契合。

當我們在設計一個微服務架構時，可以問自己：

這個服務的目的因是什麼？

如果只是因為**「大家都在用微服務」**，那就是錯誤的理由。

如果它的目的是**「支撐跨國用戶同時使用，並能快速獨立部署」**，那它才有存在的意義。

依託於哲學上的權衡能夠非常實際且有效的幫助我們從「工具崇拜」回到「目的導向」。

人性因素：團隊、溝通與決策哲學

架構不只是技術，更是團隊的共同語言。

• 溝通哲學：

• 架構師必須將抽象的技術概念翻譯成業務能聽懂的語言。

• 同時也要將業務需求翻譯成工程師能落地的設計。

• 決策哲學：

• 很多時候沒有「最佳解」，只有「當下最合適的解」。

• 例如：RDS vs DynamoDB。選擇 RDS 可能在未來遇到擴展瓶頸，但選擇 DynamoDB 則在一致性上需要更多思考。

架構師要能接受「有限理性」，並持續迭代。

30天完整學習路徑：8大階段全覽

這個系列會一同走過一個完整的系統從無到有的生命週期，每個階段都會深入AWS的具體實踐，同時強調領域思維的重要性：

階段1：產品發想與機會探索 (Day 1-4)

核心問題：系統的目的是什麼？

• 從業務領域到AWS服務選型的思維轉換
• 用DDD思想進行領域建模
• 如何在雲端時代重新思考系統邊界
• AWS Well-Architected Framework的哲學思考

階段2：需求定義與優先排序 (Day 5-8)

核心問題：領域邊界如何劃分？

• 功能性需求vs非功能性需求的AWS對應
• 從使用者故事到AWS服務的領域映射
• 成本效益分析與技術決策的平衡藝術
• Bounded Context在雲端架構中的實踐

階段3：產品設計與使用者體驗 (Day 9-12)

核心問題：用戶如何與我們的領域互動？

• API設計：從領域語言到RESTful實現
• AWS API Gateway + Lambda的領域服務設計
• 前端架構與後端領域的解耦策略
• CloudFront + S3的內容分發架構思考

階段4：技術規劃與系統設計 (Day 13-18)

核心問題：領域如何映射到技術架構？

• AWS上的微服務架構與領域邊界對應
• 資料庫選型：領域模型與RDS/DynamoDB的適配
• 事件驅動架構：AWS EventBridge的領域事件設計
• 高可用性與災難復原的系統韌性思考

階段5：軟體開發與持續整合 (Day 19-24)

核心問題：如何讓系統自動化地成長？

• Infrastructure as Code：領域基礎設施的抽象化
• CI/CD Pipeline：從代碼到部署的自動化哲學
• AWS CodePipeline的企業級實踐
• 多環境治理與領域一致性保證

階段6：驗證與品質保證 (Day 25-27)

核心問題：如何驗證系統實現了預期目的？

• 測試策略：從領域邏輯到系統行為的驗證
• AWS上的自動化測試環境搭建
• 效能測試與壓力測試的系統思考
• 領域專家與技術實現的溝通橋樑

階段7：發佈與運營監控 (Day 28-30)

核心問題：系統在生產環境中是否健康？

• 可觀測性：CloudWatch + X-Ray的系統洞察
• 告警設計與事故響應的系統化流程
• 藍綠部署與金絲雀發布的風險控制
• AWS安全最佳實踐與合規性思考

階段8：資料分析與持續改進 (Day 31-35)

核心問題：如何讓系統持續進化？

• AWS上的資料分析架構與領域洞察
• 系統度量與業務價值的對應關係
• A/B測試在雲端架構中的實現
• 系統演進策略與架構債務的哲學思考

未來展望：AI 與後人類時代的架構師角色

當 AI 能自動生成系統，架構師是否會被取代？

答案是否定的。

AI 可以自動生成代碼，但它需要「問題定義」。

架構師的價值在於「定義問題」與「界定目的」。

在後人類時代，架構師更像是「數位哲學家」，負責回答：

這個系統是否該存在？(Who am I ?)
它的邊界與責任是什麼？(Where am I from？)
它會對人類社會帶來什麼影響？(Where am I going？)

所以我認為在現在的這個世代以及未來，如何正確釐清 系統建構的最初第一性 是一個AI擁有替換不了的能力。

看完這個系列文章後，能夠獲得到以下的收穫

領域驅動的AWS架構思維：不只分享工具使用心得，更分享用領域視角思考雲端設計。

哲學深度與技術實踐並重：每個技術決策都會探討背後的「為什麼」。

多元背景的獨特視角：結合前奧美集團公關的需求與風險評估意識、美食愛好者的品質追求、登山領隊的路徑時程規劃思維。

實戰經驗分享：真實項目去業務與脈絡化經驗，包括踩坑教訓和成功實踐。

一套用領域思維駕馭AWS的完整框架、面對AI時代不會被淘汰的核心競爭力、還有從系統目的出發進行架構設計的哲學深度。

更重要的是，我們會開始用架構師的高視角俯瞰系統全貌，而不只是專注於局部的技術實現。

準備好開始這30天的旅程了嗎？接下來我們將從「需求分析與商業邏輯轉換」開始，聊聊AWS架構師如何理解系統存在的真正目的。

「系統的設計，是概念化的仿生學。我們不只是在寫代碼，更是在創造有目的、有生命力的數位生物。」